Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-067.TXT

Text File | 1992-06-03 | 46.9 KB | 1,273 lines

C.S.M.P. Digest             Sat, 02 May 92       Volume 1 : Issue 67

Today's Topics:

    Black Window Confuses Finder
    Has any body used Turbo Pascal for Macintosh?
    How do I set a page of memory to no access?
    where to find Harvest C
    More Map cdev questions
    Multifinder Friendliness Advice
    KILL! KILL! KILL! (the Finder, that is)
    Determining locale of Volume


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Bill Leue)
Subject: Black Window Confuses Finder
Date: 11 Mar 92 16:20:24 GMT
Organization: General Electric Research & Development

No, that's not "Black Widow"...:-)

Here's a strange problem I've been having.  I wrote an application
which hides the menu bar and blanks out the screen.  I hid the menu
bar using Mr. Horton's code from the USENET Mac Programming Guide.
I blanked the screen by defining a black, unornamented color window
which covers the entire screen.  The application works fine.  It's
not an extension, nor does it do anything funky to low-memory globals
except for the single hack to hide the menu bar, which it carefully
restores when exiting.

However, after this application is run, the Finder starts behaving
strangely, with black rectangles appearing under places where things
like Menus and Dialog boxes have been.  If you run an application,
everything looks cool, but when Finder reasserts itself, the black
rectangles reappear.  Somehow, my application seems to be clobbering
some Finder structures or assumptions, but I can't think what they
could be.  Sound familiar?

Environment is:  Mac IIci, 8 megs, System 7.0.

Thanks!
- -Bill Leue
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 27 Mar 92 22:14:21 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Bill Leue) writes:
>
> No, that's not "Black Widow"...:-)
>
> Here's a strange problem I've been having.  I wrote an application
> which hides the menu bar and blanks out the screen.  I hid the menu
> bar using Mr. Horton's code from the USENET Mac Programming Guide.
> I blanked the screen by defining a black, unornamented color window
> which covers the entire screen.  The application works fine.  It's
> not an extension, nor does it do anything funky to low-memory globals
> except for the single hack to hide the menu bar, which it carefully
> restores when exiting.
>
> However, after this application is run, the Finder starts behaving
> strangely, with black rectangles appearing under places where things
> like Menus and Dialog boxes have been.  If you run an application,
> everything looks cool, but when Finder reasserts itself, the black
> rectangles reappear.  Somehow, my application seems to be clobbering
> some Finder structures or assumptions, but I can't think what they
> could be.  Sound familiar?

I have seen behavior of this sort when I first started programming the Mac
and I would forget to set the port to my window. My quickdraw calls would
change the state of the window manager port.  Perhaps you should check that.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 27 Mar 92 22:14:21 GMT
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (Bill Leue) writes:
>
> No, that's not "Black Widow"...:-)
>
> Here's a strange problem I've been having.  I wrote an application
> which hides the menu bar and blanks out the screen.  I hid the menu
> bar using Mr. Horton's code from the USENET Mac Programming Guide.
> I blanked the screen by defining a black, unornamented color window
> which covers the entire screen.  The application works fine.  It's
> not an extension, nor does it do anything funky to low-memory globals
> except for the single hack to hide the menu bar, which it carefully
> restores when exiting.
>
> However, after this application is run, the Finder starts behaving
> strangely, with black rectangles appearing under places where things
> like Menus and Dialog boxes have been.  If you run an application,
> everything looks cool, but when Finder reasserts itself, the black
> rectangles reappear.  Somehow, my application seems to be clobbering
> some Finder structures or assumptions, but I can't think what they
> could be.  Sound familiar?

I have seen behavior of this sort when I first started programming the Mac
and I would forget to set the port to my window. My quickdraw calls would
change the state of the window manager port.  Perhaps you should check that.

Jon

+++++++++++++++++++++++++++

From: [e-mail] (Richard Chandler)
Date: Tue, 31 Mar 92 17:56:32 GMT
Organization: InterCon Systems Corporation

In article <[e-mail]>, [e-mail] (Jon Pugh) writes:
> > However, after this application is run, the Finder starts behaving
> > strangely, with black rectangles appearing under places where things
> > like Menus and Dialog boxes have been.  If you run an application,
> > everything looks cool, but when Finder reasserts itself, the black
> > rectangles reappear.  Somehow, my application seems to be clobbering
> > some Finder structures or assumptions, but I can't think what they
> > could be.  Sound familiar?

Yeah, the Finder seems to store offscreen bitmaps of the areas under the menu
Bar at odd times, and copies them from the Window Manager port.

> I have seen behavior of this sort when I first started programming the Mac
> and I would forget to set the port to my window. My quickdraw calls would
> change the state of the window manager port.  Perhaps you should check that.

The most bizarre thing I did in my early days was accidentally doing a
SetOrigin on the Window Manager port.  Wooo!  That was fun.  Click over here,
the menu pops down over there, then you have to go over there to select the
items....

- --
People are more violently opposed to fur than leather, because it's safer to
harass rich women than biker gangs.
"Ride a motorcycle.  Save Gas, Oil, Rubber, Steel, Aluminum, Parking Spaces,
 The Environment, and Money.  Plus, you get to wear all the leather you want!"
 Rich Chandler, DoD #296

---------------------------

From: [e-mail] (Nasir Ahmed Noor)
Subject: Has any body used Turbo Pascal for Macintosh?
Date: 18 Mar 92 04:08:31 GMT
Organization: University of Manitoba, Winnipeg, Canada



Hi,
Has any body used Turbo Pascal for macintosh? How would you rate it or
compare it against Think Pascal. I guess that turbo does not have objects, os
comparing just the pascal part, how do theses two compare. Is it worth
buying Turbo pscal?

Please post your reply.

Thanks
Nasir Ahmed Noor
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Levent Mollamustafaoglu)
Date: 18 Mar 92 06:11:21 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] (Nasir Ahmed Noor) writes:
>
>
>Hi,
>Has any body used Turbo Pascal for macintosh? How would you rate it or
>compare it against Think Pascal. I guess that turbo does not have objects, os
>comparing just the pascal part, how do theses two compare. Is it worth
>buying Turbo pscal?

It is certainly not worth, for several reasons : First of all, Turbo
Pascal has not had any new versionsince 1.0, Borland does not support
it. I am not even sure they sell it any more. Second, it was very buggy
and was never upgraded. I would heartily recommend Think Pascal. It is
very powerful, very cheap (if you can buy an educational version) and
can also be used in conjunction with Think C, if you have some C libraries.


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================

+++++++++++++++++++++++++++

From: [e-mail] (William Riel)
Date: 18 Mar 92 08:08:12 GMT
Organization: University of British Columbia, Vancouver, B.C., Canada

I used to like Turbo Pascal (but that was about 4 years ago).
I don't think that you can buy TP (for the mac) any more - as
I understand Borland stopped doing Mac software a couple of years
ago.

THINK Pascal is a far superior product.  Turbo Pascal is seriously
out of date (not even multifinder friendly - I wouldn't dare try
to use it under Sys 7).  Without question, the Pascal to buy is
Symantic's THINK. IMHO THINK Pascal is one of the nicest programming
environments available - for any platform.

Bill
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Date: 18 Mar 92 15:14:05 CST
Organization: University of Kansas Academic Computing Services

In article <[e-mail]>, [e-mail] (Nasir Ahmed Noor) writes:
>
> Hi,
> Has any body used Turbo Pascal for macintosh? How would you rate it or
> compare it against Think Pascal. I guess that turbo does not have objects, os
> comparing just the pascal part, how do theses two compare. Is it worth
> buying Turbo pscal?
>
> Please post your reply.
>
> Thanks
> Nasir Ahmed Noor
> [e-mail]

I used it about three years ago.  Turbo Pascal for the Mac is DEAD, HISTORY,
FORGET IT!  It is no longer supported by Borland, it does not have interfaces
for Color Quickdraw or anything else from IM V onward.  In fact, I didn't think
it was even possible to still buy it.  No, no OOP at all - never will have it.
THINK Pascal and MPW Pascal are the only options.

john calhoun
"...chained to the pillars / a 3-day party / i break the walls
and kill us all / with holy fingers..."  The Pixies


+++++++++++++++++++++++++++

From: [e-mail] (Dennis Cohen)
Date: 20 Mar 92 13:18:57 GMT
Organization: Claris Corporation, Santa Clara CA

[e-mail] writes:

>In article <[e-mail]>, [e-mail] (Nasir Ahmed Noor) writes:
>>
>> Hi,
>> Has any body used Turbo Pascal for macintosh? How would you rate it or
>> compare it against Think Pascal. I guess that turbo does not have objects, os
>> comparing just the pascal part, how do theses two compare. Is it worth
>> buying Turbo pscal?
>>
>> Please post your reply.
>>
>> Thanks
>> Nasir Ahmed Noor
>> [e-mail]

>I used it about three years ago.  Turbo Pascal for the Mac is DEAD, HISTORY,
>FORGET IT!  It is no longer supported by Borland, it does not have interfaces
>for Color Quickdraw or anything else from IM V onward.  In fact, I didn't think
>it was even possible to still buy it.  No, no OOP at all - never will have it.
>THINK Pascal and MPW Pascal are the only options.

Up until the last sentence, John was pretty much right on (except that I've seen
places that are still selling it).  There is a 3rd option, and that is
MetroWerks Pascal.  MW Pascal is published by MacMillan and lists for $79, with
lower, educational pricing available.  It doesn't have OOP language extensions
in the 1.0 release, but does have Turbo 5.5 source compatibility (except for
register twiddling, which is platform dependent).  The manual is a pretty
decent, textbook-appearing, hardbound volume and the environment does include
a source-level debugger; however, the debugger is not as mature as LightsBug
in THINK Pascal.  They started shipping MW Pascal just before MacWorld a
couple of months ago.


+++++++++++++++++++++++++++

From: [e-mail] (Greg Trimper)
Date: 19 Mar 92 21:03:39 GMT
Organization: Enterprise Data Systems Incorporated, Appleton WI

Turbo Pascal-

Worthless.  Is no longer supported as a product by Borland, doesn't
work on much beyond a Mac SE or II under system 6, is clumsy, useless,
and basically not worth the time or money.


THINK is quite a nice package.  I bought Turbo a few years ago,
when it was still a valid product - within a month, I had purchased
THINK and dumped Turbo.  No comparison.


                    GTr


+++++++++++++++++++++++++++

From: [e-mail]
Date: 18 Mar 92 08:06:37 GMT
Organization: McDnDSpaceSys, Huntington Bch, CA

In article <[e-mail]>, [e-mail] (William Riel) writes:
[ stuff deleted]
>
> THINK Pascal is a far superior product.  Turbo Pascal is seriously
> out of date (not even multifinder friendly - I wouldn't dare try
> to use it under Sys 7).  Without question, the Pascal to buy is
> Symantic's THINK. IMHO THINK Pascal is one of the nicest programming
> environments available - for any platform.
>

I heartily agree... but if you can get your hands on the "Turbo Tutor" for TP
for the Mac, snap it up. It's a book/disk package with a book that's one of the
best I've seen on explaining nearly all the essential parts of doing a Mac
program in Pascal(without using compiler-specific features). It spends a good
portion talking about pointers,handles, and casting with examples that aren't
terribly dry/esoteric... (Cartwright & Reed's Pascal Primer is funnier, but it
doesn't cover quite as much ground)...

Jeff Johnson
[e-mail]

---------------------------

From: [e-mail] (David Dantowitz)
Subject: How do I set a page of memory to no access?
Date: 20 Mar 92 15:54:16 GMT
Organization: UCLA Computer Science Department


I am testing some code and would like my program to trap into the debugger
when a certain address is read or written.  I'm using System 7, but could
also run the test under system 6 if need be the case.

More succinctly: I have an array and I am trying to test for access to the
array at the end of the array.  The actual resolution is not that
important, i.e., if I get a report that some address within a PAGE was
accessed, that would be sufficient.  The array has a few thousand elements,
but the error I see occurs when element 65535 is accessed (index -1) and
most of the time that indicates an error.

Thanks for any help.  There are otherways to catch such an error, but the
nature of the code makes the above solution the simplest because I can just
ask the memory manager to lock a single page of memory rather than changing
many lines of code.

Thanks,
- --
David Dantowitz
[e-mail]

Singing Barbershop when I'm not doing parallel simulation

+++++++++++++++++++++++++++

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Date: 31 Mar 92 04:19:55 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (David Dantowitz) writes:
> I am testing some code and would like my program to trap into the debugger
> when a certain address is read or written.  I'm using System 7, but could
> also run the test under system 6 if need be the case.
>
> More succinctly: I have an array and I am trying to test for access to the
> array at the end of the array.  The actual resolution is not that
> important, i.e., if I get a report that some address within a PAGE was
> accessed, that would be sufficient.  The array has a few thousand elements,
> but the error I see occurs when element 65535 is accessed (index -1) and
> most of the time that indicates an error.
>
> Thanks for any help.  There are otherways to catch such an error, but the
> nature of the code makes the above solution the simplest because I can just
> ask the memory manager to lock a single page of memory rather than changing
> many lines of code.

To test whether it's being read, you'll have to use Jasik's Debugger.  As far
as I know, it is the only program which manipulates the MMU to set up
watchpoints.  This will also do a write check.

You can test whether it's being written with MacsBug (and I think with TMON,
too).  In MacsBug, use the ss command.  This steps through your program,
checksumming a range of memory after every instruction to find out when it
changes.  Needless to say, this is _very_ slow.  For better speed, but less
resolution, use atss, which only checks at every A-trap.  This can let you
localize it to a smaller range of code, but may well be useless to you if
you're not making Toolbox calls in the nearby code.

Tim Dierks
MacDTS, but I speak for myself

---------------------------

From: [e-mail] (Tony Ng)
Subject: where to find Harvest C
Organization: University of Illinois at Urbana
Date: Sat, 21 Mar 1992 06:23:52 GMT

Can some one tell me where I can find the Harvest C compiler
or any C compilers for mac in the shareware domain?

Thanx in advance!

Tony


+++++++++++++++++++++++++++

From: [e-mail] (Ray Arachelian)
Date: 28 Mar 92 21:40:00 GMT
Organization: FidoNet node 1:2603/204 - Not Even Odd, Forest Hills NY

On 03-21-92, [e-mail] wrote to ALL:

 T> Can some one tell me where I can find the Harvest C compiler or any C
 T> compilers for mac in the shareware domain?

Get Sesame C $35 from:

 Sesame Software
 1215 S. Maple Rd. #303
 Ann Arbor, MI 48103

 * Freddie 1.1 * You have been found guilty of commerce with the devil.

- --
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 Ray Arachelian - Internet: [e-mail]

---------------------------

From: [e-mail] (Catherine Caston)
Subject: More Map cdev questions
Date: 22 Mar 92 06:35:16 GMT
Organization: Not likely!

A while back, there was a discussion of how an application can find
out the location (latitude and longitude and so on) of the machine
as set in the Map cdev. The only answer I saw posted required System 7.
Problem is, I have developed a need to do this under System 6.0.x.
I know it's possible; does anyone out there know how? Any hints, tips,
pointers, revelations welcome; code fragments (C or Pascal) joyously
received.

Thanks muchly in advance,
Melissa Reid

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Mon, 23 Mar 1992 02:32:34 GMT

In article <[e-mail]>, [e-mail] (Catherine Caston) writes:
>
> A while back, there was a discussion of how an application can find
> out the location (latitude and longitude and so on) of the machine
> as set in the Map cdev. The only answer I saw posted required System 7.
> Problem is, I have developed a need to do this under System 6.0.x.
> I know it's possible; does anyone out there know how? Any hints, tips,
> pointers, revelations welcome; code fragments (C or Pascal) joyously
> received.

The MPW interface for reading the Mac's position is...

PROCEDURE ReadLocation(VAR loc: MachineLocation);
    INLINE $205F,$203C,$000C,$00E4,$A051;

This translates to...

     MOVEA.L    (A7)+,A0          ; adr of loc into A0
     MOVE.L     #$000C00E4,D0     ; hiwrd = 12 = sizeof(loc)
                                  ; lowrd = $E4 = location in PRAM
     _ReadXPRam                   ; read the PRAM

Which is simply a call to _ReadXPRam with suitable parameter mangling.  So
there is no special trap.   You can call it regardless of what system
your running (OK, so _ReadXPRam needs to be implemented but that certainly
doesn't require System 7.).

The short answer is you can call ReadLocation on any System that implements
_ReadXPRam.  If you're *truly* paranoid check for the availability of the
_ReadXPRam trap.

That's not saying that you'll get valid data back though.  Half the world's
Macs don't have the location set correctly anyway.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia
  -- Mega-kudos to those responsible for the ResEdit CODE editor


+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 24 Mar 92 04:12:54 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] (Catherine Caston) writes:
>A while back, there was a discussion of how an application can find
>out the location (latitude and longitude and so on) of the machine
>as set in the Map cdev. The only answer I saw posted required System 7.
>Problem is, I have developed a need to do this under System 6.0.x.

I have posted the code below in the past.  I just tried it under 6.0.7
and it worked fine.  As Quinn pointed out, checking that _ReadXPRam is
implemented is about all you should have to do to ensure that this
works on any Mac.

Grobbins     [e-mail]

Usual disclaimers apply.

- ---

{
  readLocation

  retrieves the map settings for longitude and latitude and
  the time offset from GMT

  for more information, see Worldwide Development: Guide to System Software

  Greg Robbins 12/91

}

{ requires SIOW for WriteLn }

PROGRAM location;

USES Types, Script, FixMath;

VAR
    myMachineLocation: MachineLocation;
    latExt, longExt: EXTENDED;
    latDeg, latMin, longDeg, longMin: LONGINT;
    theGmtDelta, hours, minutes, seconds: LONGINT;

    FUNCTION GetGmtDelta(myLocation: MachineLocation): LONGINT;
    VAR
        internalGmtDelta: LONGINT;
    BEGIN
        { change 3-byte integer to LONGINT }
        internalGmtDelta := BAND(myLocation.gmtDelta,$00FFFFFF);
        IF BTST(internalGmtDelta,23) THEN { sign extend }
            internalGmtDelta := BOR(internalGmtDelta,$FF000000);
        GetGmtDelta := internalGmtDelta;
    END;

BEGIN
    ReadLocation(myMachineLocation);

    { convert location to extended fraction }
    latExt := Frac2X(myMachineLocation.latitude);
    longExt := Frac2X(myMachineLocation.longitude);

    { convert location to degrees-minutes }
    latDeg := TRUNC(latExt * 90);
    latMin := TRUNC((latExt * 90 - latDeg) * 60);

    longDeg := TRUNC(longExt * 90);
    longMin := TRUNC((longExt * 90 - longDeg) * 60);

    { find time zone w.r.t. GMT }
    theGmtDelta := GetGmtDelta(myMachineLocation);
    hours := theGmtDelta DIV 3600;
    minutes := (theGmtDelta MOD 3600) DIV 60;
    seconds := theGmtDelta MOD 60;

    { negative values indicate South or West }
    WriteLn('latitude:  ', latDeg, CHR($A1), latMin, CHR($27));
    WriteLn('longitude: ', longDeg, CHR($A1), longMin, CHR($27));

    { negative values indicate West }
    WriteLn('time from GMT: ', hours:3, ' h ', minutes:3, ' m ',
        seconds:2, ' s');
END.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 26 Mar 92 23:26:59 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Catherine Caston) writes:
>
> A while back, there was a discussion of how an application can find
> out the location (latitude and longitude and so on) of the machine
> as set in the Map cdev. The only answer I saw posted required System 7.
> Problem is, I have developed a need to do this under System 6.0.x.
> I know it's possible; does anyone out there know how? Any hints, tips,
> pointers, revelations welcome; code fragments (C or Pascal) joyously
> received.
>
> Thanks muchly in advance,
> Melissa Reid

You can call the routine ReadLocation which returns the latitude and longitude
of the machine.  These values are kept in Parameter RAM.  The problem is that
if the user has not set these values for their location, then you cannot
rely on them.  The Map cdev is the only way to set them, and it works under
System 6.0.x.  Again, you cannot determine if the user has set their
location properly so you can make use ReadLocation but cannot know if it's
correct.


- -----------------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 30 Mar 1992 21:57:15 GMT

[e-mail] (Jim Reekes) writes:
>System 6.0.x.  Again, you cannot determine if the user has set their
>location properly so you can make use ReadLocation but cannot know if it's
>correct.

While you can't tell if the user has done it correctly, you can tell if
the user has done it at all.  All three values will be 0 if the user
has never set the location.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

---------------------------

From: [e-mail]
Subject: Multifinder Friendliness Advice
Date: 22 Mar 92 20:17:24 GMT
Organization: New Jersey Institute of Technology


    Not having the Programmer's Guide to Multifinder handy (or the cash to
buy it) I need a little basic advice about making my program Multifinder
friendly. (If there's a particular tech note anybody could point me
towards that would be great.) The first thing I need to know is what
sort of sleep value I should pass to WaitNextEvent to give a reasonable
amount of time to other applications running in the background.
    The second question is about Suspend and Resume Events, as in what are
they? What sends them? and how should I respond to them. Currently I
simply stop processing if I get a Suspend event and resume processing if
I get a resume event. Is there more to it than that? Here's my current
suspend and resume event code for comparison:

 case app4Evt:
          if ( ( gTheEvent.message & SUSPEND_RESUME_BIT) == RESUMING ) {
                    go = TRUE;
                    makenewboard();
                }
                else
                    go = FALSE;
                break;

In particular is the "&" symbol above correct or should it be &&? I just
copied this piece of the code from a book and that & looks a little
suspicious.

Elliotte Rusty Harold        Department of Applied Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07103

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 26 Mar 92 04:50:07 GMT
Organization: Dartmouth College, Hanover, NH

First thing, use WaitNextEvent, but you know about sleep values so you
know about WaitNextEvent. If you use TextEdit, you should pass a value
less than the caret time. The fast time is 15 ticks, but if you want to
be tricky, you can get the blink time (Bits 0-3 of the volClick field)
and set the sleep value to the blink time-1. If you don't use textEdit
(textEdit includes editText items in dialogs) you can set it anything
you want, but I hear times greater than 50 ticks will crash certain
machines. If you have a simple app. that doesn't do stuff in the
background, set the time as high as you can, you won't be doind
anything if there aren't any events anyway.
Suspend and resume, they are events which you get through
waitNextEvent.
Anyway, on suspend you set the cursor to something reasonable, hide any
floating windows, un-hilite any selections, and convert the scrap if it
needs it. On resume you first set the current grafPort to a known good
one (It's supposed to be done automatically, but I hear some programs
can mess that up), then call beginUpdate convert the scrap if it needs
it, erase and re-dray any text and graphics, and call endUpate.
More on all of this in TN's 169, 2, 126, 158, 177, 180, 185,190, 194,
202, 205, and 233.

Hope I helped,
Jeremiah

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Thu, 26 Mar 1992 17:18:04 GMT

Some nits to be picked:

In article <[e-mail]> [e-mail] writes:
[_WaitNextEvent sleep values greater than 50 will crash certain machines]
The sleep time bug exists only on machines running the original
Multifinder, that is, pre-System 6.

>Suspend and resume, they are events which you get through
>waitNextEvent.

Suspend/resume (both are event 15, by the way) is an event you get if your
application's SIZE resource specifies that such events are supported.
Both _WaitNextEvent and _GetNextEvent will return them.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 26 Mar 92 20:55:38 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.dartmouth.edu> [e-mail] (Jeremiah Blatz) writes:

   less than the caret time. The fast time is 15 ticks, but if you want to
   be tricky, you can get the blink time (Bits 0-3 of the volClick field)
   and set the sleep value to the blink time-1. If you don't use textEdit

Hey, that's a roundabout and incompatible way of doing something
that the trap GetCaretTime() will return for free...

   (textEdit includes editText items in dialogs) you can set it anything
   you want, but I hear times greater than 50 ticks will crash certain
   machines. If you have a simple app. that doesn't do stuff in the

No, that only applies to system 4.2. (i.e. multifinder 1.0)
Anyone running system 6.0 and later will not be affected.
DTS sample code passes 0x7fffffff to WaitNextEvent when
nothing happens.

   Anyway, on suspend you set the cursor to something reasonable, hide any
   floating windows, un-hilite any selections, and convert the scrap if it
   needs it. On resume you first set the current grafPort to a known good

On suspend you don't touch the cursor.

   one (It's supposed to be done automatically, but I hear some programs
   can mess that up), then call beginUpdate convert the scrap if it needs
   it, erase and re-dray any text and graphics, and call endUpate.

I don't think you need to re-draw anything, or call beginupdate/endupdate
either. What you NEED to do is handling deactivation/activation of
your windows on suspend/resume; updates will take care of themselves.

   More on all of this in TN's 169, 2, 126, 158, 177, 180, 185,190, 194,
   202, 205, and 233.

And Inside Mac VI, which does NOT only contain systemm 7 stuff.

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Lloyd Lim)
Date: 28 Mar 92 02:48:26 GMT
Organization: U.C. Davis - Department of Computer Science

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>.dartmouth.edu> [e-mail] (Jeremiah Blatz) writes:
>
>   (textEdit includes editText items in dialogs) you can set it anything
>   you want, but I hear times greater than 50 ticks will crash certain
>   machines. If you have a simple app. that doesn't do stuff in the
>
>No, that only applies to system 4.2. (i.e. multifinder 1.0)
>Anyone running system 6.0 and later will not be affected.
>DTS sample code passes 0x7fffffff to WaitNextEvent when
>nothing happens.

True, but there is another bug which is similar.  With System 6.0.x, if you
pass a large sleep value like 0x7FFFFFFF, MultiFinder will not call
SystemTask when everything is sleeping.  This is very noticeable because
things like SuperClock and screensavers will never activate.  This bug
is fixed in System 7.

I mentioned this bug here a while ago and some Apple people confirmed it.
I guess they don't think it's really a bug because I haven't seen it
documented.  Anyway, I use 50 ticks in these circumstances to make sure
that screensavers will kick in.

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616

+++++++++++++++++++++++++++

From: [e-mail] (Lloyd Lim)
Date: 28 Mar 92 02:48:26 GMT
Organization: U.C. Davis - Department of Computer Science

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>.dartmouth.edu> [e-mail] (Jeremiah Blatz) writes:
>
>   (textEdit includes editText items in dialogs) you can set it anything
>   you want, but I hear times greater than 50 ticks will crash certain
>   machines. If you have a simple app. that doesn't do stuff in the
>
>No, that only applies to system 4.2. (i.e. multifinder 1.0)
>Anyone running system 6.0 and later will not be affected.
>DTS sample code passes 0x7fffffff to WaitNextEvent when
>nothing happens.

True, but there is another bug which is similar.  With System 6.0.x, if you
pass a large sleep value like 0x7FFFFFFF, MultiFinder will not call
SystemTask when everything is sleeping.  This is very noticeable because
things like SuperClock and screensavers will never activate.  This bug
is fixed in System 7.

I mentioned this bug here a while ago and some Apple people confirmed it.
I guess they don't think it's really a bug because I haven't seen it
documented.  Anyway, I use 50 ticks in these circumstances to make sure
that screensavers will kick in.

+++
Lloyd Lim     Internet: [e-mail]
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 224 Lysle Leach Hall, U.C. Davis, Davis, CA 95616

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 31 Mar 92 03:21:25 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Jon W{tte) writes:

> I don't think you need to re-draw anything, or call beginupdate/endupdate
> either. What you NEED to do is handling deactivation/activation of
> your windows on suspend/resume; updates will take care of themselves.

I don't claim to be an expert or anything, so I'll quote Apple. This is
the System 7.0 version of "Sample", included with MPW Object Pascal.

PROCEDURE DoUpdate(window: WindowPtr);

{This is called when an update event is received for a window.
 It calls DrawWindow to draw the contents of an application window.
 As an effeciency measure that does not have to be followed, it
 calls the drawing routine only if the visRgn is non-empty. This
 will handle situations where calculations for drawing or drawing
 itself is very time-consuming.}

BEGIN
    IF IsAppWindow(window) THEN BEGIN
        BeginUpdate(window);                    {sets up the visRgn, clears updateRgn}
        IF NOT EmptyRgn(window^.visRgn) THEN    {draw if updating needs to be
done}
            DrawWindow(window);
        EndUpdate(window);                        {restores the visRgn}
    END;
END; {DoUpdate}

If Apple does it, then I'll think twice about not doing it.

Jeremiah
[e-mail]
The opinions expressed are mine only, and not those of Apple Computer,
Dartmouth College, Johnny Carson, Dan Quale, Pat Robertson (at least, I
hope not), or anyone you will ever know exists. MPW is probably a
trademark of someone of other.

+++++++++++++++++++++++++++

From: [e-mail] (Doug McNought)
Organization: California Institute of Technology
Date: Tue, 31 Mar 1992 13:39:24 GMT

In article <[e-mail]> [e-mail] (Jeremiah Blatz) writes:
>In article <[e-mail]>
>[e-mail] (Jon W{tte) writes:
>
>> I don't think you need to re-draw anything, or call beginupdate/endupdate
>> either. What you NEED to do is handling deactivation/activation of
>> your windows on suspend/resume; updates will take care of themselves.
>
>I don't claim to be an expert or anything, so I'll quote Apple. This is
>the System 7.0 version of "Sample", included with MPW Object Pascal.
>
>PROCEDURE DoUpdate(window: WindowPtr);

  [Apple sample code for update handling deleted]

>If Apple does it, then I'll think twice about not doing it.
>
>Jeremiah
>[e-mail]

  Yes, but the original question was "what do I do in response to a *resume*
event?" You don't need to handle updating in that case; the Window Manager
will generate an update event in the normal manner if one is necessary (which
it very well might not be).
regards,
doug
- --
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>
<> Doug McNaught                          [e-mail] <>
<>  Help!!! I'm addicted to *Spaceward Ho!* Is there a support group? <>
<><><><><><><><><><><><><><><>Go Orioles<><><><><><><><><><><><><><><><>

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 31 Mar 92 15:30:16 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.dartmouth.edu> [e-mail] (Jeremiah Blatz) writes:

   [e-mail] (Jon W{tte) writes:

   > I don't think you need to re-draw anything, or call beginupdate/endupdate
   > either. What you NEED to do is handling deactivation/activation of
   > your windows on suspend/resume; updates will take care of themselves.
                     ^^^^^^^^^^^^^^

   I don't claim to be an expert or anything, so I'll quote Apple. This is
   the System 7.0 version of "Sample", included with MPW Object Pascal.

   PROCEDURE DoUpdate(window: WindowPtr);

   {This is called when an update event is received for a window.
    It calls DrawWindow to draw the contents of an application window.
    As an effeciency measure that does not have to be followed, it
    calls the drawing routine only if the visRgn is non-empty. This
    will handle situations where calculations for drawing or drawing
    itself is very time-consuming.}

   If Apple does it, then I'll think twice about not doing it.


Well, DoUpdate is of course very nice for updating the window, but
you dont have to update windows on suspend/resume, since if they need
updating, you'll get an update event anyway. The only reason you might
want to do this is performance, since updates are prioritized pretty
low, it might take a millisecond or two before you get the update
event, especially if the user starts typing right away.

However, you need to activate/deactivate your (frontmost) windows on
suspend/resume; this might require you to repaint the window anyway
because of selections that change between outlines/inverted.

CHeers,

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

---------------------------

From: [e-mail] (Paul Robichaux)
Subject: KILL! KILL! KILL! (the Finder, that is)
Organization: New Technology, Inc.
Date: Mon, 23 Mar 1992 14:52:55 GMT

I'm writing an application which needs to run without the finder. For
testing, I'd like to stick in an AESend that kills the finder.

The widely famous "Bride of FinderEvents" stack doesn't mention a
special quit event. Does Finder 7.0 support the core 'quit'? Is there
some other special event?

I'll summarize replies, since I'm sure others have had this question
(or will.)

- -Paul
- --
Paul Robichaux, KD4JZG          | NTI doesn't pay for my opinions, and NASA
[e-mail]   | doesn't know I have any.
         This message printed on recycled phosphors.


+++++++++++++++++++++++++++

From: [e-mail] (Robert Hess)
Date: 29 Mar 92 18:34:49 GMT
Organization: Independent Consultant

In article <[e-mail]>, [e-mail] (Paul Robichaux) writes:
> Does Finder 7.0 support the core 'quit'?

yes.

---------------------------

From: [e-mail] (Joe Francis)
Subject: Determining locale of Volume
Date: 24 Mar 92 07:48:24 GMT
Organization: Dartmouth College, Hanover, NH

I want to use the Desktop Manager to find an application.  However, I
am only interested in matching applications that are on the target
machine, rather than fileshared volumes from other machines or remote
appleshare volumes.  How can I determine what volumes fit my needs? I
looked at the param block filled by PBHGetVolParms() and couldn't find
a combination of attributes that looked to fit the bill.  Any clues?

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Wed, 25 Mar 1992 04:27:37 GMT

In article <[e-mail]>, [e-mail] (Joe Francis) writes:
>
> I want to use the Desktop Manager to find an application.  However, I
> am only interested in matching applications that are on the target
> machine, rather than fileshared volumes from other machines or remote
> appleshare volumes.  How can I determine what volumes fit my needs? I
> looked at the param block filled by PBHGetVolParms() and couldn't find
> a combination of attributes that looked to fit the bill.  Any clues?

One way that should work is to check that the volume's server address is
zero:

[This code probably won't compile, but it is taken from some code that
definitely uses the address field so I know it works in principle]

var
  pb: HParamBlockRec;
  volparams: packed record
    version: integer;
    attrib: longInt;
    localhand: handle;
    address: AddrBlock;
  end;
  volname:str255;

begin
  with pb do begin
    ioNamePtr := @volname;
    ioVRefNum := 0;
    ioVolIndex := i;
    oe := PBHGetVInfoSync(@pb);
    if oe = noErr then begin
      ioNamePtr := nil;
      ioBuffer := @volparams;
      ioReqCount := SizeOf(volparams);
      oe := PBHGetVolParmsSync(@pb);
    end;
    if oe = noErr then begin
      if longInt(volparams.address) = 0 then begin
        IsLocal;
      end else begin
        IsRemote
      end;
    end;
  end;
end.

HTH,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]



+++++++++++++++++++++++++++

From: [e-mail] (Grobbins)
Date: 25 Mar 92 21:43:15 GMT
Organization: Apple DTS

In article <[e-mail]> [e-mail] writes:
>I am only interested in matching applications that are on the target
>machine, rather than fileshared volumes from other machines or remote
>appleshare volumes.  How can I determine what volumes fit my needs? I
>looked at the param block filled by PBHGetVolParms() and couldn't find
>a combination of attributes that looked to fit the bill.  Any clues?

Pasted below are an appropriate entry from the Q&A Stack (available on
the Developer CD and, I hope, at ftp.apple.com) and a useful routine
for locating the preferred application given its documents file spec.

Grobbins           [e-mail]

Usual disclaimers apply.

- ---

from the Q&A Stack:

If I don't want to search any AppleShare or File Sharing volumes, how can I
tell which mounted volume to search?

You should be able to use the field vMServerAdr in the GetVolParmsInfo
attributes buffer of PBHGetVolParms to determine whether to search a volume.
Since the vMServerAdr field specifies the internet address of the server
that manages an AppleTalk server volume, checking for a zero internet
address before searching the volume would seem the way to go for you.

- ---



  FUNCTION FindAppFromDoc(docFSSpec: FSSpec; VAR appFSSpec: FSSpec): OSErr;
  { first find an app on the same volume; next try local volumes;
    next try remote volumes.  System 7 only. }

  LABEL 1;
  TYPE
    volumePass = (document, local, remote, done);

  VAR
    myDTPBRec: DTPBRec;
    docFInfo, dummyFInfo: FInfo;
    retCode: OSErr;
    theVolumePass: volumePass;
    theVolumeCounter: INTEGER;

    myHParamBlockRec: HParamBlockRec;
    myGetVolParmsInfoBuffer: GetVolParmsInfoBuffer;
    remoteFlag, foundFlag: BOOLEAN;

  BEGIN

    theVolumePass := document;
    foundFlag := FALSE;

    retCode := FSpGetFInfo(docFSSpec, docFInfo);
    IF retCode <> noErr THEN GOTO 1;

    REPEAT  { for each kind of pass }

      theVolumeCounter := 0;

      REPEAT  { for each volume, except on first pass }

        { first, find the vRefNum of the volume to be checked }

        IF theVolumePass = document THEN { use doc's own volume }
          myDTPBRec.ioVRefNum := docFSSpec.vRefNum
        ELSE
          BEGIN
            theVolumeCounter := theVolumeCounter + 1;

            { loop through all drives }
            myHParamBlockRec.ioCompletion := NIL;
            myHParamBlockRec.ioNamePtr := NIL;
            myHParamBlockRec.ioVRefNum := 0;
            myHParamBlockRec.ioVolIndex := theVolumeCounter;
            retCode := PBHGetVInfoSync(@myHParamBlockRec);

            IF retCode = nsvErr THEN Leave; { checked all drives }
            IF retCode <> noErr THEN GOTO 1;

            { is this one remote? }
            myHParamBlockRec.ioBuffer := @myGetVolParmsInfoBuffer;
            myHParamBlockRec.ioReqCount :=
              Sizeof(myGetVolParmsInfoBuffer);
            retCode := PBHGetVolParmsSync(@myHParamBlockRec);
            IF (retCode <> noErr) THEN GOTO 1;

            { volume should be remote only on remote pass, else skip it }
            IF (myGetVolParmsInfoBuffer.vMServerAdr <> 0)
              <> (theVolumePass = remote) THEN Cycle;

            { found a volume of interest }
            myDTPBRec.ioVRefNum := myHParamBlockRec.ioVRefNum;

          END; { ELSE }

        myDTPBRec.ioNamePtr := NIL;

        { Get the application name and directory from the desktop database, if
          the volume has one. }

        retCode := PBDTGetPath(@myDTPBRec);
        IF (retCode = noErr) AND (myDTPBRec.ioResult = noErr) AND
          (myDTPBRec.ioDTRefNum <> 0) THEN
          BEGIN
            { get application name and directory }
            myDTPBRec.ioNamePtr := @appFSSpec.name; { change the file spec name }
            myDTPBRec.ioIndex := 0;
            myDTPBRec.ioFileCreator := docFInfo.fdCreator;
            myDTPBRec.ioCompletion := NIL;

            retCode := PBDTGetAPPLSync(@myDTPBRec);
            IF retCode = noErr THEN
              BEGIN
                appFSSpec.parID := myDTPBRec.ioAPPLParID;
                appFSSpec.vRefNum := myDTPBRec.ioVRefNum;
                foundFlag := TRUE;
              END;
          END;

      UNTIL foundFlag OR (theVolumePass = document);
        { OR ran out of drives, due to Leave statement }

      theVolumePass := SUCC(theVolumePass)

    UNTIL foundFlag OR (theVolumePass = done);

    IF NOT foundFlag THEN retCode := fnfErr;
  1:
    FindAppFromDoc := retCode;
  END;


+++++++++++++++++++++++++++

From: [e-mail] (Joe Francis)
Date: 31 Mar 92 21:57:08 GMT
Organization: Dartmouth College, Hanover, NH

Thanks for the replies, everyone.  Using the vMServerAdr field of the
GetVolParmsInfo buffer works like a charm.

---------------------------

End of C.S.M.P. Digest
**********************